Bug 8012019

Bug Description:

This is a deadlock bug.

" test thread 2" prio=6 tid=0x000000000ea96000 nid=0x2068 waiting for monitor entry [0x000000000f02f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at sun.nio.ch.FileDispatcherImpl.pread(FileDispatcherImpl.java:61)
    - waiting to lock <0x00000007d5f6f078> (a java.lang.Object)
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:222)
    at sun.nio.ch.IOUtil.read(IOUtil.java:198)
    at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:674)
    at Test8012019$1.run(Test8012019.java:94)
    at java.lang.Thread.run(Thread.java:722)


" test thread 1" prio=6 tid=0x000000000e99c000 nid=0x20a8 in Object.wait() [0x000000000ef2f000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000007d5f6f040> (a sun.nio.ch.NativeThreadSet)
    at java.lang.Object.wait(Object.java:503)
    at sun.nio.ch.NativeThreadSet.signalAndWait(NativeThreadSet.java:102)
    - locked <0x00000007d5f6f040> (a sun.nio.ch.NativeThreadSet)
    at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:114)
    at java.nio.channels.spi.AbstractInterruptibleChannel$1.interrupt(AbstractInterruptibleChannel.java:165)
    - locked <0x00000007d5f6f030> (a java.lang.Object)
    at java.nio.channels.spi.AbstractInterruptibleChannel.begin(AbstractInterruptibleChannel.java:173)
    at sun.nio.ch.FileChannelImpl.size(FileChannelImpl.java:289)
    - locked <0x00000007d5f6f078> (a java.lang.Object)
    at Test8012019$1.run(Test8012019.java:96)
    at java.lang.Thread.run(Thread.java:722)

    
"main" prio=6 tid=0x0000000002d1e000 nid=0x3624 waiting for monitor entry [0x0000000002caf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at java.nio.channels.spi.AbstractInterruptibleChannel$1.interrupt(AbstractInterruptibleChannel.java:160)
    - waiting to lock <0x00000007d5f6f030> (a java.lang.Object)
    at java.lang.Thread.interrupt(Thread.java:935)
    - locked <0x00000007d5f6fbe0> (a java.lang.Object)
    at Test8012019.stopThread(Test8012019.java:74)
    at Test8012019.runTest(Test8012019.java:65)
    at Test8012019.main(Test8012019.java:30)
	

In this case, " test thread 1 " has been interrupted by the main thread and is attempting to close the file channel. It is waiting in NativeThreadSet.signalAndWait() for 'used' to count down to 0. " test thread 2 " is the one that is supposed to make this change by calling NativeThreadSet.remove(), but that thread is waiting for a lock (FileChannelImpl.positionLock) that is held by the first test thread. Finally, the main thread is also blocked, waiting for another lock that is held by the first test thread.

How To Reproduce:

This bug is reproduced under JDK 1.7.0_17.
It started at JDK 1.7.0_17, and has been fixed since JDK 1.7.0_40. And it affects Windows ONLY.
Execute the following scripts to run the test to reproduce the bug (assume the location of the jdk7 test project is jdk7_test_home).

Linux:
${jdk7_test_home}/scripts/8012019.sh [--monitoroff] [--javaloc path]
Windows:
%jdk7_test_home%\scripts\8012019.bat [--monitoroff] [--javaloc path]

Example:
Use monitor to report and terminate the program when deadlock happens:
${jdk_test_home}/scripts/8012019.sh

Turn off monitor:
${jdk_test_home}/scripts/8012019.sh --monitoroff